Background and problem statements are awesome, but I will take some time to process the rest. Just the small thing about services: for now.

@stevesloka this is a fantastic design document, thanks!!

Just putting my two cents:

• Route matching is not needed in tcp proxying and the current design seems to require it.
• Is it possible to add a note to explicitly say that all the maching rules in route are additive (AND)?

Thank you for working on this. I'm sorry it has taken me several days to reply, there is a lot to digest here.

I would like you to break this design into smaller pieces. As I see it there are 3-4 major pieces of work here

1. The renaming of ingressroute fields; service -> backends, and name -> protocol hint. This is independant of any routing or delegation discussion. I think we can do this in a backwards compatible way in beta1 by introducing a new backends field with the protocol named fields and deprecating service. When we move to ingressroute v1, we'll remove service.
2. The Issues with the current design section is great to have all those things together as we want to make sure they are addressed before v1, but perhaps some of them can be addressed cheaply without being rolled into this design. For example Permit Insecure in multi-team environments #864 could be addressed by a permitInsecure: false flag in the contour serve config we're going to do in 0.14 contour serve should take its configuration from a configuration file #1130. Maybe its possible to chip away at those outstanding issues independantly of this design.
3. Header based routing. I'd like to step back a bit and define, before talking about the implementation, the things Ingressroute v1 will let users route on. Headers is well covered in this document, but what about client ip? What about HTTP method? What about path globbing, suffix routing, substring matching, query string matching, and so on. I'm wary of designing for the things we know how to do well without having a holistic plan for other kinds of routing we might be asked for.
4. Healthcheck failure policy. Similar to 1. I think these can be separated out and treated independently. I wasn't aware that these were a problem and hopefully we can address them cheaply in ingressroute beta1 similar to point 1.

Routing design vs ingressroute design

This proposal operates at many levels; talking about the ingressroute limitations and bugs, a fleshed out section on header routing, but is noncommittal on other kinds of path based routing other than our current prefix matching. Routing is going to be a huge topic by itself, I'd really like to see it pulled out into its own proposal -- even if that means that this proposal, or any discussion of ingressroute v1 is put on hold.

Routing is the key deliverable, I see little value in delivering ingressroute v1, even incorporating the other sub areas outlined above, unless we have a better routing story so let's concentrate on that. Key to this is to define a list of the types of things that we want contour 1.0 users to be able to route on. Let's start there, without being drwaing to closely into the how, but stay at the level of saying "we want to let you route like this so you can do X". This is as much a process of saying what we will allow users to route on as it is one of excluding things we will not permit routing on. As an example, I do not think we can support regex path matching, I don't see how that can interoperate with delegation, but I think we can support glob style, /foo/*/bar matching.

My suggestion is to start a new document for just the routing component of ingressroute; just the match key, and working only at the high level, declare the things we will let users route on.

As for the other areas in this design such as backend name protocol hints, and healthcheck policies, we can tear these off and work on them in parallel.